Don't we need to register the types for our tests? I think that was the only thing preventing us from using the geth rpc package

The only place we registered was in an additional main file just in subnet-evm, and that was for test retrying for flakes. I removed that as we should not be doing test retries in the monorepo, and should just skip flaky tests entirely if they're flaky. Is there registration anywhere else?

Don't we need to register the types for our tests? I think that was the only thing preventing us from using the geth rpc package

The only place we registered was in an additional main file just in subnet-evm, and that was for test retrying for flakes. I removed that as we should not be doing test retries in the monorepo, and should just skip flaky tests entirely if they're flaky. Is there registration anywhere else?

No, we didn't just retry failed tests. They also registered customtypes in each respective repo, so that's why the contents of the block changed when you moved them over. I'm not sure if we still need to be testing that functionality

Don't we need to register the types for our tests? I think that was the only thing preventing us from using the geth rpc package

The only place we registered was in an additional main file just in subnet-evm, and that was for test retrying for flakes. I removed that as we should not be doing test retries in the monorepo, and should just skip flaky tests entirely if they're flaky. Is there registration anywhere else?

No, we didn't just retry failed tests. They also registered customtypes in each respective repo, so that's why the contents of the block changed when you moved them over. I'm not sure if we still need to be testing that functionality

I don't think this is true. There are two places in this PR where I removed customtypes.Register().

1. For a test retry loop. As explained above, I this this is unnecessary.
2. In TestMain of subnet-evm's subscription test. This differed from coreth, and only appeared to be present as we were still importing the old custom types instead of the libevm types package. I removed it to align the two, as I assume subnet-evm just didn't get updated.

Are there other important places in which I removed it?

If customtypes.Register() isn't called then the test isn't testing coreth / subnet-evm functionality in its entirety. I'd recommend using evm.RegisterLibEVMExtras() (which calls customtypes.Register()) instead of the individual registration as this guarantees that all hooks/payloads are registered.

This can alternately be done with emulate.CChain() and emulate.SubnetEVM() if you need to test both in the same package (i.e. the same test binary). If there is commonality between the testing then the best approach is probably something like:

func testCChainAndSubnetEVM(t *testing.T, testFn func(*testing.T)) {
  fn := func() error {
    testFn(t)
    return nil
  }

  t.Run("cchain", func(t *testing.T) {
    _ = emulate.CChain(fn)
  })
  t.Run("subnetEVM", func(t *testing.T) {
    _ = emulate.SubnetEVM(fn)
  })
}

func TestFoo(t *testing.T) {
  testCorethAndSubnetEVM(t, testFoo)
}

func testFoo(t *testing.T) {
  // this is where the actual testing occurs; i.e. just rename any existing TestFoo to testFoo
}

func TestBar(t *testing.T) {
  testCorethAndSubnetEVM(t, testBar)
}

func testBar(t *testing.T) {
  // as with testFoo()
}

The linter is going to tell you to call t.Helper() but it's better not to in this case otherwise all errors will be reported as being on the single line of the TestFoo() implementation, instead of on the specific line in testFoo().

I believe we have decided to enforce that we don't want cyclic dependencies between coreth and evm, so we would probably have to "uplift" the customtypes packages first. Also, I have tried this in #4688, and trying to register all EVM imports in this package causes a cyclic dependency (unless you make a test package?)

I believe we have decided to enforce that we don't want cyclic dependencies between coreth and evm, so we would probably have to "uplift" the customtypes packages first. Also, I have tried this in #4688, and trying to register all EVM imports in this package causes a cyclic dependency (unless you make a test package?)

Yeah I am trying this right now and was about to comment about the cyclic imports. The shared graft/evm/rpc package is a dependency used by coreth, which creates a circular dependency if we try to use vms/evm/emulate (which depends on coreth) in the RPC tests. This can be avoided if we just call the custom types registration directly or put it in a seperate test package.

I definitely think this + in conjunction with some sort of test main would be a good model for how to combine packages while testing separately. I've committed a new main_test.go which does this to some extent although simpler. What are the thoughts on this approach?

After extensive discussion, we have decided not to test under registration.